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Abstract 


A mobile node needs at least the following information: a home 
address, a home agent address, and a security association with home 
agent to register with the home agent. The process of obtaining this 
information is called bootstrapping. This document discusses issues 
involved with how the mobile node can be bootstrapped for Mobile IPv6 
(MIPv6) and various potential deployment scenarios for mobile node 
bootstrapping. 
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1. Introduction 


Mobile IPv6 [RFC3775] specifies mobility support based on the 
assumption that a mobile node (MN) has a trust relationship with an 
entity called the home agent. Once the home agent address has been 
learned (for example, via manual configuration, anycast discovery 
mechanisms, or DNS lookup), Mobile IPv6 signaling messages between 
the mobile node and the home agent are secured with IPsec or with the 
authentication protocol, as defined in [RFC4285]. The requirements 
for this security architecture are created with [RFC3775], and the 
details of this procedure are described in [RFC3776]. 


In [RFC3775], there is an implicit requirement that the MN be 
provisioned with enough information that will permit it to register 
successfully with its home agent. However, having this information 
statically provisioned creates practical deployment issues. 


This document serves to define the problem of bootstrapping. 
Bootstrapping is defined as the process of obtaining enough 
information at the mobile node that it can successfully register with 
an appropriate home agent. 


The requirements for bootstrapping could consider various 
scenarios/network deployment issues. It is the basic assumption of 
this document that certain minimal parameters (seed information) are 
available to the mobile node to aid in bootstrapping. The exact seed 
information available differs depending on the deployment scenario. 
This document describes various deployment scenarios and provides a 
set of minimal parameters that are available in each deployment 
scenario. 
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This document stops short of suggesting the preferred solutions for 
how the mobile node should obtain information. Such details will be 
available from separate documents. 


1.1. Overview of the Problem 


Mobile IPv6 [RFC3775] expects the mobile node to have a static home 
address, a home agent address (which can be derived from an anycast 
address), and a security association with a home agent (or multiple 
home agents). 


This static provisioning of information has various problems, as 
discussed in Section 5. 


The aim of this document is: 
o To define bootstrapping; 


o To identify sample deployment scenarios where Mobile Internet 
Protocol version 6 (MIPv6) will be deployed, taking into account 
the relationship between the subscriber and the service provider; 
and 


o To identify the minimal set of information required on the Mobile 
Node and in the network in order for the mobile node to obtain 
address and security credentials, to register with the home agent. 


1.2. Bootstrapping 


Bootstrapping is defined as obtaining enough information at the 
mobile node that the mobile node can successfully register with an 
appropriate home agent. Specifically, this means obtaining the home 
agent address and home address, and for the mobile node and home 
agent to authenticate and mutually construct security credentials for 
Mobile IPv6. 


Typically, bootstrapping happens when a mobile node does not have all 
the information it needs to set up the Mobile IPv6 service. This 
includes, but is not limited to, situations in which the mobile node 
does not having any information when it boots up for the first time 
(out of the box), or does not retain any information during reboots. 


Also, in certain scenarios, after the MN bootstraps for the first 
time (out of the box), the need for subsequent bootstrapping is 
implementation dependent. For instance, the MN may bootstrap every 
time it boots, bootstrap every time on prefix change, or bootstrap 
periodically to anchor to an optimal HA (based on distance, load, 
etc.). 
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1.3. Terminology 


General mobility terminology can be found in [RFC3753]. The 
following additional terms are used here: 


Trust relationship 


In the context of this document, trust relationship means that the 
two parties in question, typically the user of the mobile host and 
the mobility or access service authorizer, have some sort of prior 
contact in which the mobile node was provisioned with credentials. 
These credentials allow the mobile node to authenticate itself to 
the mobility or access service provider and to prove its 
authorization to obtain service. 


Infrastructureless relationship 


In the context of this document, an infrastructureless 
relationship is one in which the user of the mobile node and the 
mobility or access service provider have no previous contact and 
the mobile node is not required to supply credentials to 
authenticate and prove authorization for service. Mobility and/or 
network access service is provided without any authentication or 
authorization. Infrastructureless in this context does not mean 
that there is no network infrastructure, such as would be the case 
for an ad hoc network. 


Credentials 


Data used by a mobile node to authenticate itself to a mobility or 
access network service authorizer and to prove authorization to 
receive service. User name/passwords, one time password cards, 
public/private key pairs with certificates, and biometric 
information are some examples. 


ASA 


Access Service Authorizer. A network operator that authenticates 
a mobile node and establishes the mobile node’s authorization to 
receive Internet service. 


ASP 


Access Service Provider. A network operator that provides direct 
IP packet forwarding to and from the end host. 
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Serving Network Access Provider 


A network operator that is the mobile node’s ASP but not its ASA. 
The serving network access provider may or may not additionally 
provide mobility service. 


Home Network Access Provider 


A network operator that is both the mobile node’s ASP and ASA. 
The home network access provider may or may not additionally 
provide mobility service (note that this is a slightly different 
definition from that in RFC 3775). 


IASP 
Integrated Access Service Provider. A service provider that 
provides both authorization for network access and mobility 


service. 


MSA 


Mobility Service Authorizer. A service provider that authorizes 
Mobile IPv6 service. 


MSP 


Mobility Service Provider. A service provider that provides 


Mobile IPv6 service. In order to obtain such service, the mobile 
node must be authenticated and prove authorization to obtain the 
service. 


Home Mobility Service Provider 
A MSP that both provides mobility service and authorizes it. 
Serving Mobility Service Provider 


A MSP that provides mobility service but depends on another 
service provider to authorize it. 


2. Assumptions 


o A basic assumption in Mobile IPv6 [RFC3775] is that there is a 
trust relationship between the mobile node and its home agent (s). 
This trust relationship can be direct, or indirect through, for 
instance, an ASP that has a contract with the MSP. This trust 
relationship can be used to bootstrap the MN. 
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3s 


One typical way of verifying the trust relationship is using 
authentication, authorization, and accounting (AAA) 
infrastructure. In this document, two distinct uses of AAA are 
considered: 


AAA for Network Access 


This functionality provides authentication and authorization to 
access the network (obtain address and send/receive packets). 


AAA for Mobility Service 


This functionality provides authentication and authorization 
for mobility services. 


These functionalities may be implemented in a single entity or in 
different entities, depending on the service models described in 
Section 6 or deployment scenarios as described in Section 7. 


Some identifier, such as an Network Access Identifier (NAI), as 
defined in [RFC4283] or [RFC2794], is provisioned on the MN that 
permits the MN to identify itself to the ASP and MSP. 


Design Goals 


A solution to the bootstrapping problem has the following design 
goals: 


(0) 


The following information must be available at the end of 
bootstrapping, to enable the MN to register with the HA. 


* MN’s home agent address 
* MN’s home address 


* IPsec Security Association (SA) between MN and HA, Intenet Key 
Exchange Protocol (IKE) pre-shared secret between MN and HA 


The bootstrapping procedure can be triggered at any time, either 
by the MN or by the network. Bootstrapping can occur, for 
instance, due to administrative action, information going stale, 
or HA indicating the MN. Bootstrapping may be initiated even when 
the MN is registered with the HA and has all the required 
credentials. This may typically happen to refresh/renew the 
credentials. 
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Subsequent protocol interaction (for example, updating the IPsec 
SA) can be executed between the MN and the HA itself without 
involving the infrastructure that was used during bootstrapping. 


Solutions to the bootstrapping problem should enable storage of 
user-specific information on entities other than the home agent. 


Solutions to the bootstrapping problem should not exclude storage 
of user-specific information on entities other than the home 
agent. 


Configuration information which is exchanged between the mobile 
node and the home agent must be secured using integrity and replay 
protection. Confidentiality protection should be provided if 
necessary. 


The solution should be applicable to all feasible deployment 
scenarios that can be envisaged, along with the relevant 
authentication/authorization models. 


Non-goals 


This following issues are clearly outside the scope of bootstrapping: 


(0) 


I3 


Jels 


Home prefix renumbering is not explicitly supported as part of 
bootstrapping. If the MN executes the bootstrap procedures every 
time it powers on (as opposed to caching state information from 
previous bootstrap process), then home network renumbering is 
taken care of automatically. 


Bootstrapping in the absence of a trust relationship between MN 
and any provider is not considered. 


Motivation for bootstrapping 


Addressing 


The default bootstrapping described in the Mobile IPv6 base 
specification [RFC3775] has a tight binding to the home addresses and 
home agent addresses. 


In this section, we discuss the problems caused by the currently 
tight binding to home addresses and home agent addresses. 


Saks 


Dynamic Home Address Assignment 


Currently, the home agent uses the mobile node’s home address for 
authorization. When manual keying is used, this happens through the 
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security policy database, which specifies that a certain security 
association may only be used for a specific home address. When 
dynamic keying is used, the home agent ensures that the IKE Phase 1 
identity is authorized to request security associations for the given 
home address. Mobile IPv6 uses IKEv1l, which is unable to update the 
security policy database according to a dynamically assigned home 
address. As a result, static home address assignment is really the 
only home address configuration technique compatible with the base 
specification. 


However, support for dynamic home address assignment would be 
desirable for the following reasons: 


Dynamic Host Configuration Protocol (DHCP)-based address assignment. 
Some providers may want to use DHCPv6 or other dynamic address 
assignment (e.g., IKEv2) from the home network to configure home 
addresses. 


Recovery from a duplicate address collision. It may be necessary to 
recover from a collision of addresses on the home network by one of 
the mobile nodes changing its home address. 


Addressing privacy. It may be desirable to establish randomly 
generated addresses as in [RFC3041] and use them for a short period 
of time. Unfortunately, current protocols make it possible to use 
such addresses only from the visited network. As a result, these 
addresses cannot be used for communications lasting longer than the 
attachment to a particular visited network. 


Ease of deployment. In order to simplify the deployment of Mobile 
IPv6, it is desirable to free users and administrators from the task 
of allocating home addresses and specifying them in the security 
policy database. This is consistent with the general IPv6 design 
goal of using autoconfiguration wherever possible. 


Prefix changes in the home network. The Mobile IPv6 specification 
contains support for a mobile node to autoconfigure a home address as 
based on its discovery of prefix information on the home subnet 
[RFC3775]. Autoconfiguration in case of network renumbering is done 
by replacing the existing network prefix with the new network prefix. 


Subsequently, the MN needs to update the mobility binding in the HA 
to register the newly configured Home Address. However, the MN may 
not be able to register the newly configured address with the HA if a 
security association related to that reconfigured Home Address does 
not exist in the MN and the HA. This situation is not handled in the 
current MIPv6 specification [RFC3775]. 
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5.1.2. Dynamic Home Agent Assignment 


Currently, the address of the home agent is specified in the security 
policy database. Support for multiple home agents requires the 
configuration of multiple security policy database entries. 


However, support for dynamic home agent assignment would be desirable 
for the following reasons: 


Home agent discovery. The Mobile IPv6 specification contains support 
for a mobile node to autoconfigure a home agent address as based on a 
discovery protocol [RFC3775]. 


Independent network management. An MSP may want to assign home 
agents dynamically in different subnets; for instance, not require 
that a roaming mobile node have a fixed home subnet. 


Local home agents. The mobile node’s MSP may want to allow the 
serving MSP to assign a local home agent for the mobile node. This 
is useful from the point of view of communications efficiency and has 
also been mentioned as one approach to support location privacy. 


Ease of deployment. In order to simplify the deployment of Mobile 
IPv6, it is desirable to free users and administrators from the task 
of allocating home agent addresses in a static manner. Moreover, an 
MSP may want to have a dynamic home agent assignment mechanism to 
load balance users among home agents located on different links. 


5.1.3. "Opportunistic" or "Local" Discovery 


The home agent discovery protocol does not support an "opportunistic" 
or local discovery mechanisms in an ASP’s local access network. It 
is expected that the mobile node must know the prefix of the home 
subnet in order to be able to discover a home agent. It must either 
obtain that information through prefix update or have it statically 
configured. A more typical pattern for inter-domain service 
discovery in the Internet is that the client (mobile node in this 
case) knows the domain name of the service and uses DNS to find the 
server in the visited domain. For local service discovery, DHCP is 
typically used. 


5.1.4. Management Requirements 


As described earlier, new addresses invalidate configured security 
policy databases and authorization tables. Regardless of the 
specific protocols used, there is a need for either an automatic 
system for updating the security policy entries or manual 
configuration. These requirements apply to both home agents and 
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mobile nodes, but it cannot be expected that mobile node users are 
capable of performing the required tasks. 


5.2. Security Infrastructure 
5.2.1. Integration with AAA Infrastructure 


The current IKEvl-based dynamic key exchange protocol, described in 
[RFC3776], has no integration with backend authentication, 
authorization, and accounting techniques unless the authentication 
credentials and trust relationships use certificates or pre-shared 
secrets. 


Certificates are not easily supported by traditional AAA 
infrastructures. Where a traditional AAA infrastructure is used, the 
home agent is not able to leverage authentication and authorization 
information established between the mobile node, the foreign AAA 
server, and the home AAA server. This would be desirable when the 
mobile node gains access to the foreign network, in order to 
authenticate the mobile node’s identity and determine whether the 
mobile node is authorized for mobility service. 


The lack of connection to the AAA infrastructure also means that the 
home agent does not know where to send accounting records at 
appropriate times during the mobile node’s session, as determined by 
the business relationship between the MSP and the mobile node’s 
owner. 


Presumably, some backend AAA protocol between the home agent and home 
AAA could be utilized, but IKEv1 does not contain support for 
exchanging full AAA credentials with the mobile node. It is 
worthwhile to note that IKEv2 provides this feature. 


5.3. Topology Change 
5.3.1. Dormant Mode Mobile Nodes 


The description of the protocol to push prefix information to mobile 
nodes in Section 10.6 of [RFC3775] has an implicit assumption that 
the mobile node is active and taking IP traffic. In fact, many, if 
not most, mobile devices will be in a low power "dormant mode" to 
save battery power, or will even be switched off, so they will miss 
any propagation of prefix information. As a practical matter, if 
this protocol is used, an MSP will need to keep the old prefix around 
and handle any queries to the old home agent anycast address on the 
old subnet, whereby the mobile node asks for a new home agent as 
described in Section 11.4, until all mobile nodes are accounted for. 
Even then, since some mobile nodes are likely to be turned off for 
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long periods, some owners would need to be contacted by other means, 
reducing the utility of the protocol. 


Bootstrapping does not explicitly try to solve this problem of home 
network renumbering when MN is in dormant mode. If the MN can 
configure itself after it ’comes back on’ by reinitiating the 
bootstrapping process, then network renumbering problem is fixed as a 
side effect. 


6. Network Access and Mobility Services 


This section defines some terms as they pertain to authentication and 
practical network deployment/roaming scenarios. This description 
lays the groundwork for Section 7. The focus is on the ’service’ 
model since, ultimately, it is the provider providing the service 
that wants to authenticate the mobile (and vice versa for mutual 
authentication between provider and the user of the service). 


Network access service enables a host to send and receive IP packets 
on the Internet or an intranet. IP address configuration and IP 
packet forwarding capabilities are required to deliver this service. 
A network operator providing this service is called an access service 
provider (ASP). An ASP can, for example, be a commercial ASP, the IT 
department of an enterprise network, or the maintainer of a home 
(residential) network. 


If the mobile node is not directly usable for communication at the 
current location of the MN in which network access service is 
provided by its home ASP, the mobile node is roaming. In this case, 
the home ASP acts as the access service authorizer, but the actual 
network access is provided by the serving network access provider. 
During the authentication and authorization prior to the mobile nodes 
having Internet access, the serving network access provider may 
simply act as a routing agent for authentication and authorization 
back to the access service authorizer, or it may require an 
additional authentication and authorization step itself. An example 
of a roaming situation is when a business person is using a hotspot 
service in an airport and the hotspot service provider has a roaming 
agreement with the business person’s cellular provider. In that 
case, the hotspot network is acting as the serving network access 
provider, and the cellular network is acting as the access service 
authorizer. When the business person moves from the hotspot network 
to the cellular network, the cellular network is both the home access 
service provider and the access service authorizer. 


Mobility service using Mobile IPv6 is conceptually and possibly also 


in practice separate from network access service, though of course 
network access is required prior to providing mobility. Mobile IPv6 
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service enables an IPv6 host to maintain its reachability despite 


changing its network attachment point (subnets). A network operator 
providing Mobile IPv6 service is called a mobility service provider 
(MSP). Granting Mobile IPv6 service requires that a host 


authenticate and prove authorization for the service. A network 
operator that authenticates a mobile node and authorizes mobility 
service is called a mobility service authorizer (MSA). If both types 
of operation are performed by the same operator, that operator is 
called a home mobility service provider. If authentication and 
authorization is provided by one operator and the actual service is 
provided by another, the operator providing the service is called the 
serving mobility service provider. The serving MSP must contact the 
mobile node’s mobility service authorizer to check the mobile node’s 
authorization prior to granting mobility service. 


The service model defined here clearly separates the entity providing 
the service from the entity that authenticates and authorizes the 
service. In the case of basic network access, this supports the 
traditional and well-known roaming model, in which inter-operator 
roaming agreements allow a host to obtain network access in areas 
where their home network access provider does not have coverage. In 
the case of mobility service, this allows a roaming mobile node to 
obtain mobility service in the local operator’s network while having 
that service authorized by the home operator. The service model also 
allows mobility service and network access service to be provided by 
different entities. This allows a network operator with no wireless 
access, such as, for example, an enterprise network operator, to 
deploy a Mobile IPv6 home agent for mobility service while the actual 
wireless network access is provided by the serving network access 
providers with which the enterprise operator has a contract. Here 
are some other possible combinations of ASPs and MSPs: 


o The serving ASP might be the home ASP. Similarly, the serving MSP 
might be the home MSP. 


o The home ASP and the home MSP may be the same operator, or not. 
When they are the same, the same set of credentials may be used 
for both services. 


o The serving ASP and the serving MSP may be the same operator, or 
not. 


o It is possible that serving ASP and home MSP are the same 
operator. 


Similarly the home ASP and serving MSP may be the same. Also, the 
ASA and MSA may be the same. 
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These entities and all combinations that are reasonable from a 
deployment perspective must be taken into consideration to solve the 
Mobile IPv6 bootstrapping problem. They impact home agent discovery, 
home address configuration, and mobile node-to-home agent 
authentication aspects. 


7. Deployment Scenarios 
This section describes the various network deployment scenarios. The 
various combinations of service providers described in Section 6 are 
considered. 


For each scenario, the underlying assumptions are described. The 
basic assumption is that there is a trust relationship between mobile 
user and the MSA. Typically, this trust relationship is between the 
mobile user and AAA in the MSA’s network. Seed information needed to 
bootstrap the mobile node is considered in two cases: 


o AAA authentication is mandatory for network access. 

o AAA authentication is not part of network access. 

The seed information is described further in Section 8. 
7.1. Mobility Service Subscription Scenario 


Many commercial deployments are based on the assumption that mobile 
nodes have a subscription with a service provider. In this scenario 
the MN has a subscription with an MSA, also called the home MSP, for 
Mobile IPv6 service. As stated in Section 6, the MSP is responsible 
for setting up a home agent on a subnet that acts as a Mobile IPv6 
home link. As a consequence, the home MSP should explicitly 
authorize and control the whole bootstrapping procedure. 


Since the MN is assumed to have a pre-established trust relationship 
with its home provider, it must be configured with an identity and 
credentials; for instance, an NAI and a shared secret by some out- 
of-band means (i.e., manual configuration) before bootstrapping. 


In order to guarantee ubiquitous service, the MN should be able to 
bootstrap MIPv6 operations with its home MSP from any possible access 
location, such as an open network or a network managed by an ASP, 
that may be different from the MSP and that may not have any pre- 
established trust relationship with it. 
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7.2. Integrated ASP Network Scenario 
In this scenario, the ASA and MSA are the same entity. The MN has 
security credentials for access to the network, and these credentials 


can also be used to bootstrap MIPv6. 


Figure 1 describes an AAA design example for integrated ASP scenario. 


4---------------------------- + 
| IASP (ASA+MSA) | 
+----+ +----- + +----+ | 
| mN |--- | NAS | | HA | | 
+----+ +----—- + +----+ | 
| \ \ | 
| \ +------ +  \ +-----—- + | 

-| AAA-NA | —|AAA-MIP | 

4+------ + 4+------- + 
4+---------------------------- + 


NAS: Network Access Server 
AAA-NA: AAA for network access 
AAA-MIP: AAA for Mobile IP service 


Figure 1. Integrated ASP network 
7.3. Third-Party MSP Scenario 


Mobility service has traditionally been provided by the same entity 
that authenticates and authorizes the subscriber for network access. 
This is certainly the only model supported by the base Mobile IPv6 
specification. 


In the third-party mobility service provider scenario, the 
subscription for mobility service is made with one entity (the MSA, 
is for instance, a corporate), but the actual mobility service is 
provided by yet another entity (such as an operator specializing in 
this service, the serving MSP). These two entities have a trust 
relationship. Transitive trust among the mobile node and these two 
entities may be used to assure the participants that they are dealing 
with trustworthy peers. 


This arrangement is similar to the visited - home operator roaming 
arrangement for network access. 
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Figure 2 describes an example of a network for the third-party MSP 
scenario. 


4+-------------- +  +-------- + 
| | | Serving | 
| ASP | | MSP | 
+----+ +----—- + | | +----+ | 
| MN |--- | Nas | | | | HA | | +------------------- + 
+----+ +----- + ===| +----+ | MSA 
| A | \ | (e.g., corporate NW) 
| ere ane ne On ee : | 
| -|AAA-NA| | fo 00 =----—- | AAA-MIP | | 
| += || | | +------- - | 
+------------ +  +-------- + +------------------- + 


Figure 2. Third-Party MSP network 
Infrastructure-less Scenario 


Infrastructure refers to network entities like AAA, Public-Key 
Infrastructure (PKI), and Home Location Register (HLR). 
"Infrastructure-less" implies that there is no dependency on any 
elements in the network with which the user has any form of trust 
relationship. 


In such a scenario, there is absolutely no relationship between host 
and infrastructure. 


A good example of infrastructure-less environment for MIPv6 
bootstrapping is the IETF network at IETF meetings. It is possible 
that there could be MIP6 service available on this network (i.e., a 
MIPv6é HA). However, there is not really any AAA infrastructure or, 
for that matter, any trust relationship that a user attending the 
meeting has with any entity in the network. 


This specific scenario is not supported in this document. The reason 
for this is described in Section 9. 


Parameters for Authentication 


The following is a list of parameters that are used as the seed for 
the bootstrapping procedure. The parameters vary depending on 
whether authentication for network access is independent of 
authentication for mobility services. If different client identities 
are used for network access and mobility services, authentication for 
network access is independent of authentication for mobility 
services. 


Patel & Giaretta Informational [Page 15] 


RFC 4640 PS Bootstrapping Mobile IPv6 September 2006 


(0) 


Parameter Set 1 


In this case, authentication for network access is independent of 
authentication for mobility services. 


If the home agent address is not known to the mobile node, the 
following parameter is needed for discovering the home agent 
address: 


* The domain name or Fully Qualified Domain Name (FQDN) of the 
home agent 


This parameter may be derived in various ways, such as (but not 
limited to) static configuration, use of the domain name from the 
network access NAI (even if AAA for network access is not 
otherwise used), or use of the domain name of the serving ASP, 
where the domain name may be obtained via DHCP in the serving ASP. 


If the home agent address is not known but the home subnet prefix 
is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may 
be used for discovering the home agent address, and the above 
parameter may not be used. 


When the home agent address is known to the mobile node, the 
following parameter is needed for performing mutual authentication 


a 


between the mobile node and the home agent by using IKE: 


* IKE credentials (*) 


In the case where the home agent does not have the entire set of 
IKE credentials, the home agent may communicate with another 
entity (for example, an AAA server) to perform mutual 
authentication in IKE. In such a case, the IKE credentials 
include the credentials used between the mobile node and the other 
entity. In the case where an AAA protocol is used for the 
communication between the home agent and the other entity during 
the IKE procedure, AAA for Mobile IPv6 service may be involved in 
IKE. If the authentication protocol [RFC4285] is used, the shared 
key-based security association with the home agent is needed. 


Parameter Set 2 


In this case, some dependency exists between authentication for 
network access and authentication for mobility services in that a 
security association that is established as a result of 
authentication for network access is re-used for authentication 
for mobility services. 
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All required information, including IKE credentials, is 
bootstrapped from the following parameter: 


* Network access credentials (*) 


(*) A pair of an NAI and a pre-shared secret is an example of a set 
of credentials. A pair of an NAI and a public key, which may be 
provided as a digital certificate, is another example of a set of 
credentials. 


9. Security Considerations 


There are two aspects of security for the Mobile IPv6 bootstrapping 
problem: 


1. The security requirements imposed on the outcome of the 
bootstrapping process by RFC 3775 and other RFCs used by Mobile 
IPv6 for security. 


2. The security of the bootstrapping process itself, in the sense of 
threats to the bootstrapping process imposed by active or passive 
attackers. 


Note that the two are related; if the bootstrapping process is 
compromised, the level of security required by RFC 3775 may not be 
achieved. 


The following two sections discuss these issues. 
9.1. Security Requirements of Mobile IPv6 


The Mobile IPv6 specification in RFC 3775 requires the establishment 
of a collection of IPsec SAs between the home agent and mobile node 
to secure the signaling traffic for Mobile IP, and, optionally, also 
to secure data traffic. The security of an IPsec SA required by the 
relevant IPsec RFCs must be quite strong. Provisioning of keys and 
other cryptographic material during the establishment of the SA 
through bootstrapping must be done in a manner such that authenticity 
is proved and confidentiality is ensured. In addition, the 
generation of any keying material or other cryptographic material for 
the SA must be done in a way such that the probability of compromise 
after the SA is in place is minimized. The best way to minimize the 
probability of such a compromise is to have the cryptographic 
material only known or calculable by the two end nodes that share the 
SA -- in this case, the home agent and mobile node. If other parties 
are involved in establishing the SA (through key distribution, for 
example) the process should follow the constraints designed to 
provide equivalent security. 
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RFC 3775 also requires a trust relationship, as defined in Section 
1.3, between the mobile node and its home agent(s). This is 
necessary, for instance, to ensure that fraudulent mobile nodes that 
attempt to flood other mobile nodes with traffic be not only shut off 
but tracked down. An infrastructureless relationship as defined in 
Section 1.3 does not satisfy this requirement. Any bootstrapping 
solution must include a trust relationship between mobile node and 
mobility service provider. Solutions that depend on an 
infrastructureless relationship are out of scope for bootstrapping. 


Another requirement is that a home address be authorized to one 

specific host at a time. RFC 3775 requires this so that misbehaving 
mobile nodes can be shut down. This implies that, in addition to the 
IPsec SA, the home agent must somehow authorize the mobile node for a 


home address. The authorization can be either implicit (for example, 
as a side effect of the authentication for mobility service) or 
explicit. The authorization can either be done at the time the SA is 


created or be dynamically managed through a first come, first served 
allocation policy. 


9.2. Threats to the Bootstrapping Process 


Various attacks are possible on the bootstrapping process itself. 
These attacks can compromise the process such that the RFC 3775 
requirements for Mobile IP security are not met, or they can serve 
simply to disrupt the process such that bootstrapping cannot be 
completed. Here are some possible attacks: 


o An attacking network entity purporting to offer the mobile node a 
legitimate home agent address or bootstrapping for the IPsec SAs 
may instead offer a bogus home agent address or configure bogus 
SAs that allow the home agent to steal the mobile node’s traffic 
or otherwise disrupt the mobile node’s mobility service. 


o An attacking mobile node may attempt to steal mobility service by 
offering up fake credentials to a bootstrapping network entity or 
otherwise disrupting the home agent’s ability to offer mobility 
service. 


o A man in the middle on the link between the mobile node and the 
bootstrapping network entity could steal credentials or other 
sensitive information and use that to steal mobility service or 


deny it to the legitimate owner of the credentials. Refer to 
Section 7.15 in [RFC3748] and [AAA-EAP-LLA] for further 
information. 
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o An attacker could arrange for a distributed denial-of-service 
attack on the bootstrapping entity, to disrupt legitimate users 
from bootstrapping. 


In addition to these attacks, there are other considerations that are 
important in achieving a good security design. As mobility and 
network access authentication are separate services, keys generated 
for these services need to be cryptographically separate, to be 


separately named, and to have separate lifetimes. This needs to be 
achieved even though the keys are generated from the same 
authentication credentials. This is necessary because a mobile node 


must be able to move from one serving (or roaming) network access 
provider to another without needing to change its mobility access 
provider. Finally, basic cryptographic processes must provide for 
multiple algorithms in order to accommodate the widely varying 
deployment needs; the need for replacement of algorithms when attacks 
become possible must also be considered in the design. 
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